Posts tagged with 'unit testing'
Jeremy Clark is writing unit tests.
Show Notes:
- David Neal was a guest on the podcast, episode 010
- Regression tests - Change Code Without Fear
- Code coverage (NCover is a tool that reports on code coverage for .NET code)
- TDD and BDD and ATDD
- WPF and XML, MVVM
- Book: The Art of Unit Testing, by Roy Osherove
- Jeremy's website, Jeremy Bytes
- Jeremy Clark on Pluralsight
- Jeremy Clark on YouTube
Want to be on the next episode? You can! All you need is the willingness to talk about something technical.
Theme music is "Crosscutting Concerns" by The Dirty Truckers, check out their music on Amazon or iTunes.
Jesse Riley and I discuss unit testing and how to do it better.
Show Notes:
- Jon Kruger has a blog and Jon Kruger is on Twitter
- Martin Fowler discusses mocks and stubs, and mentions the "Detroit" and "London" schools
- Jesse Riley's post on Where to Draw the Line on a Unit Test
- One of the mocking frameworks we discussed was Moq
- The other one we discussed was Typemock
- The testing framework for JavaScript we discussed is called Jasmine
- The Pair Programming technique was discussed
- Jesse Riley's post on Sanity Tests for Your Sanity
- Book: Test-Driven Development by Kent Beck
Want to be on the next episode? You can! All you need is the willingness to talk about something technical.
Theme music is "Crosscutting Concerns" by The Dirty Truckers, check out their music on Amazon or iTune
It's the last part of the series, and I just thought I would wrap things up by talking about unit testing the aspect. I wrote a whole chapter in my book AOP in .NET on unit-testing of aspects. I also was honored to do a live webinar with Gael Fraiteur on unit testing with PostSharp, in which he has a different view on aspect unit testing, so I recommend you check that out too.
I'm not straying too much from the book in this example, so if you're familiar with that chapter, there's not much new for you here.
My plan is to not test the PostSharp aspect directly, but instead have the aspect delegate just about all the functionality to a plain old C# class that's easier to test. The old adage of solving a problem by adding another layer of indirection applies. Doing it this way makes my aspect easier to test, further decouples my application from a specific framework, but does require some more work, so it's not like it's a magic cost-free approach to testing either.
Here is the aspect, all tightly coupled to PostSharp:
And here is my refactored code, which you'll notice results in a higher number of classes, but it is ready to unit test. You may also notice that some of the logic is a bit different than the above aspect. This is because I found some issues and bugs while I was writing unit tests. So, hooray for unit tests! Also notice the "On" static field. I touch on this in the book, but this flag is merely there so that I can unit test the actual services while isolating them from the aspect. Since PostSharp uses a compile-time weaver, this is necessary. If you are using a runtime AOP weaver like Castle DynamicProxy, that's not necessary.
I'll even show you some of my unit tests, which I've written in mspec and JustMock Lite with the help of Sticking Place for testing the SqlException stuff.
Notice that I moved the Exceptionless-specific code behind an interface (IExceptionLogger) as well, to further decouple, improve testability, and also because Exceptionless is just the sort of thing that might actually be swapped out somewhere down the line. I've left out the details of that implementation because it's quite trivial.
So now you are caught up to today: this is the aspect I'm actually using and deploying to a staging site for my cofounder and our designer to use and test. And so far I must say that it's working quite well, but things could always change when it actually hits real customers, of course.
